Software instrumentation generally includes software entities used for collecting, storing and retrieving performance metrics of a computer system. These software entities typically include writer entities for collecting the performance information and storing that information in a designated area of main memory, called a repository. The repository preferably holds the performance information for retrieval by reader entities, which may include application programs executing on the computer.
Namespace services impose a uniform structure on the information stored in repositories. A namespace is a collection of information managed by an operating system of the computer and a namespace service, or registry, is the entity that stores and organizes that information. The registry generally provides an application programming interface (API), which is a mechanism for an application program to obtain services from the operating system. APIs typically include a collection of system calls to the operating system requesting, for example, establishment of network connections on behalf of an application. Specifically, the application may, via system calls to the registry API, create, modify, request, add and delete information in the registry.
The performance information collected at the registry typically includes metrics relating to components of the computer system, such as a central processor unit (CPU), main memory, the operating system and input/output (I/O) system. Examples of the collected information include loading metrics of the CPU and bandwidth parameters of the memory, along with timing latencies for execution of a particular request involving the I/O system, e.g., how long it takes to complete the (entire or portions of the) request.
By collecting and retrieving performance information, the software instrumentation provides access to the internal state and behavior, i.e., "views", of the operating system and application software executing on the computer. Operating systems are complex pieces of software configured to, e.g., handle asynchronous events within a computer (such as interrupts from I/O devices), provide interprocess communication capabilities and implement complex network protocols. Operating systems also control execution of application programs; instances of those programs in execution are called processes.
Knowledge of the internal characteristics of an operating system and application processes is useful for debugging, optimization and design verification of a computer. The internal views provided by software instrumentation fall into two general categories: (i) tracing, which provides a view into the behavior of a software program by recording the time and details of its state at interesting points in a running system, and (ii) statistics, which record when and how resources, such as device drivers of the operating system, are used.
Tracing is a form of interprocess communication that enables a process to observe the execution of another process; a trace, therefore, consists of a display that chronicles the actions and results of that program execution. Specifically, the trace provides a detailed record of the program's execution path by, e.g., taking an application program and placing it under observation by a special routine that monitors the progress of the program.
Typically, primitive abstract data types are used by the writer entities to collect performance information, such as statistics and traces. These primitive data types generally include simple counters, histograms, maximum values, minimum values, averages and rates. In many cases, it may be desirable to expand upon the kinds of performance information collected by the writer entities to further enhance knowledge of the internal characteristics of software executing on the computer. In order to extend the types of information collected at the registry, however, it is necessary to describe that information so that the reader entities can manipulate the information.
A conventional way of describing type information involves designating name, type, length and offset parameters for each primitive data type. For example, a "flat" C data structure struct, set forth below, comprises primitive data type elements such as an integer of maximum value, an integer of minimum value, an unsigned count and a 64-bit int64 value.
______________________________________ struct { int max int min unsigned count int64 valuesum }; name type length (bytes) offset (bytes) ______________________________________ "max" MAX 4 0 "min" MIN 4 4 "count" COUNTER 4 8 "valuesum" SUM 8 16 ______________________________________
Referring to the first primitive data type element shown above, max is the name of the integer data element having a type designator MAX, a length of 4 bytes and an offset, relative to the beginning of the structure, of 0 bytes.
This description convention is generally used for describing parameters of trace messages as well as statistics information stored in the registry. The data type elements, e.g., int, int, unsigned and int64, are primitive in that they are implemented by the hardware of the computer, whereas type designators max, min, count, and valuesum are abstract data types using those primitive data types.
Several known operating systems have capabilities to acquire and register performance information, such as trace messages and statistics. The UNIX.RTM. operating system uses various software entities, known as KMEM readers, to access performance information stored in data structures within privileged memory for purposes of, e.g., displaying that information. Here, the performance information is collected solely within the operating system and registration is effected with a symbol table of a compiler.
In UNIX, the description of data must be previously known to the readers because there is no description of the information in the running system. That is, data description information must be compiled into the KMEM readers. Since the readers must be aware of all possible data types prior to accessing the information, the extensibility of data collection is limited.
Another known registration mechanism allows applications to access performance information without knowledge of the various types of collected information. In other words, applications can query the operating system as to the existence and types of collected information. However, there is no mechanism in the operating system for describing newly-created data types for collecting performance information. Accordingly, although the collected information can be easily added to the registry, the reader entities must have knowledge of their types in order to access them.
Therefore, it is among the objects of the invention to provide a mechanism for extending the types of information collected and stored in a registry.
Another object of the present invention is to provide a mechanism for describing the kinds of information collected and stored in a registry.